Larger enterprises often employ fairly complex print shop architectures to address their various printing needs. For example, members of an organization may use local printers for simple desktop publishing (e.g., letters, memorandums, pictures, etc.). However, when the organization requires more sophisticated and/or larger volume printing, the organization may employ a print shop architecture comprising a number of higher-end printers (e.g., multifunction printers, production printing systems, etc.) that are capable of providing more functionality and/or print volume.
These print shop architectures are typically managed by a print server that is operable to receive print jobs from a plurality of clients via host system devices (e.g., networked computer systems, mobile devices, etc.). The seamless integration of the printers in such an environment, however, is often difficult to implement. For example, printers and their specific capabilities may not be fully recognized by individual client devices. The print server is configured to manage the hardware and software assets of all the printers in the print shop architecture such that a user can easily identify a particular printer. In this centralized print environment, system administrators and other information technology personnel can also access and control the features of the printers.
Typically, the print server is configured with a plurality of features and protocols of the various printers controlled by the print server. For example, each printer managed by the print server may have its own print capabilities (e.g., double-sided printing, stapling, collation, etc.) and/or print protocols (Hot Folder, Job Definition Format or “JDF”, Job Messaging Format or “JMF”, line printer or “LPR”), that differ from other printers in the print shop architecture. Before such centralized management, a client device would install a printer driver that included the printing capabilities of the printer. The printer driver also establishes the print protocol for the client device to communicate with and control the printer. The print server maintains the printer drivers for the physical printer.
The print server presents this functionality to the client device such that a user may print a document to a particular physical printer. For example, when a user wishes to print a document to a particular physical printer, the user may communicate with the print server to access that physical printer. Prior to printing a particular print job, a client may occasionally wish to know the print capabilities and other options that may be available on a particular printer. In such a case, the client may transfer a query to the printer to obtain the device capabilities or “DEVCAPS” of the printer. These queries are operable to trigger a response by the printer to return all of the print capabilities of the printer. With the print capabilities of the printer in hand, the client may generate a print job and transfer the print job to the physical printer via the print server for printing.
This type of user defined access to the printer capabilities can circumvent the principles of centralized printer management in a print shop architecture. That is, a system administrator (or a print shop operator) managing the print shop architecture may implement a policy that precludes a client from accessing certain printer features so as to suit the particular printing needs of an organization. Present protocol standards of the devices within a print shop architecture, however, provide no means for hiding these features from the client. Accordingly, the client may expect a print job with a particular set of features that is actually printed with undesired features.